1. Field of Invention
The present invention relates generally to the field of resource bundles. More specifically, the present invention is related to the management of JAVA resource bundles via a graphical user interface (GUI).
2. Discussion of Prior Art
Today's international high-tech marketplace has created a need for global applications and Web-delivered content. As more and more companies attempt to accommodate their customers' needs and internationalize their offerings, the challenges of managing the technology and resources are emerging.
It is estimated that in less than five years, more than half of the users on the Internet will not read English, yet the vast majority of information and marketing currently available on the World Wide Web has no other translation. The increasing value of internationalized content has resulted in a focused effort to provide programmers with the tools and APIs necessary to reach a global audience. Recognizing that internationalizing the development process really meant creating an integrated framework of localization, IBM® and Sun® worked together to develop the international components first introduced in the 1.1 version of the Java® Application Program Interface (API).
Project managers and team leaders naturally gravitate toward a platform such as Java that is friendly to the developer. While the Java platform has much to offer the developer in terms of succinct international code, lurking in the shadows are problems that have plagued localization efforts in all environments.
Included in the Java 1.1 API are the “java.text” package and the “ResourceBundle” classes contained in the “java.util” package which, together with the Locale classes, make up the backbone of localization on the Java platform. Resource bundles use a cascading mechanism to provide the best translation support with the minimal amount of work for both the developer and resources of the computer. In this scheme, the developer creates files that define a lookup table for translation and adds an encoding to the names of these files to specify the locale of the file. For instance, if the developer chose to use property files to represent the lookup tables, they might look like this:
Sample property files:
# The Base Class File
# File Name: sample.properties
theater=Theater
opera=Opera
orchestra=Orchestra
# English File
# File Name: sample_en.properties
# British English File
# File Name: sample_en_GB.properties
theater=Theatre
Each file is named according to the convention base class+‘_’+encodings+‘.properties’. In this case, the base class is named “sample”. The first file represents the default translations and therefore is not given any encoding information. The translations in this file are not restricted to any one locale. The encodings appended to all other file names are made up of short abbreviations representing the language name, country, and variant of the locale that the file pertains to. The language and country abbreviations are based on ISO standards, and de facto standards exist for a limited number of variants on the locales. To better understand the process, consider a developer trying to create resource files for a program to be used in both the United States and Great Britain. The developer would have to create a base class file, “sample.properties”, and a file representing common translations in English, “sample_en.properties”. Assuming that the base class file contained translations in American English, the developer would then have to create a file containing British English variations, “sample_en_GB.properties”, or may create a file even more specifically targeting British English where the Euro currency is used, “sample_en_GB_EURO.properties”.
Within these resource files, lines starting with the “#” or “!” character are ignored as comments. All other lines represent a name/value pair with a lookup name on the left of the equal sign (=) and its corresponding translation value on the right. As will be seen in later code examples, Java programmers can specify a locale and retrieve the appropriate translation for that locale through a resource bundle. If the lookup value is not found in the file exactly corresponding to the locale specified by the programmer, the resource bundle cascades down the encoding chain successively until a translation is found. To illustrate this point, suppose a developer writes a code that accesses the sample resource file above, and that the code written by the developer queries for the “orchestra” translation in the context of the en_GB locale. The internal workings of the API will examine the sample_en_GB file without finding the resource. The sample_en file will next be examined and found similarly to be missing the resource. As a last resort, the base class file will be examined, and the result “Orchestra” will be returned. If instead the program asks for the “theater” translation, the en_GB resource file will be examined and the result, “Theatre,” returned immediately.
In this process, the resource files can range from being empty to being completely saturated. The base class file must necessarily contain all of the lookup keys. Other files may also differ enough from their ancestors to merit complete inclusion of the resources. Other locale encodings may differ only slightly from their ancestors, and their files may require only a small subset of the total resources to function properly.
Managing a few resource files, each containing a few resources, is not a difficult job and can be handled through any basic text editor. Complications arise quickly, however, as the project grows. What starts as one or two resource files quickly multiplies into several resource files, each with their own managing translator. The first hurdle faced by developers in maintaining a resource bundle is the number of files involved in the process. As a solution, a team adopts one of two techniques. In the first, a developer accesses all of the resource files and inserts the resource into each using whatever language the developer is most familiar with. It is then the responsibility of the managers of the resource files to periodically review their files for changes. In the second technique, a developer inserts resource updates only into the base class file, leaving to the managers the responsibilities of finding the differences on their own. This is a time-consuming process and is frequently subject to error.
Java developers realize that adding localization to any Java-based project is easy to accomplish, but the functionality that is already built into the Java language needs to be used for such purposes. Perhaps the most straightforward way to localize Java code is to create a public, static class that makes use of the “ResourceBundle” and “Locale” classes in “java.util”.
The “Translator” class sample code shows the minimal amount of code necessary to start using a Translator class that is able to work across multiple locales. The class is not intended to be instantiated; all calls to be made are done so statically. To retrieve a translation, the developer calls the method “Translator.getTranslation( )” on any key. Changing the current locale is done through the set method, and the code could be extended to provide a get method for determining which locale is currently defined. By default, the program will run in the locale native to the Java virtual machine (JVM™) in use. The example below illustrates how the code might be used from within an application.
Using the Translator class:
/*** This function illustrates how a resource bundle is utilized in a Javaapplication.* The following method is a trivial and illustrative only. It returns* three entertainment options according to a passed in locale.*/public static String[] getEntertainmentOptions(Locale myLocale) {Translator.setLocale(myLocale);String options[] = { Translator.getTranslation(“theater”),Translator.getTranslation(“opera”),Translator.getTranslation (“orchestra”)};return options;}
In crafting a translation file, one size does not always fit all. The examples thus far have been at the word level only. Suppose a program needed to interact with the user to determine first one's name and then age. The easiest way to do this would be to define two resource pairs. The first could be represented by “name_question=What is your name?”. The second could be represented by, “age_question=How old are you?”. These two phrases could then be translated appropriately in the various resource files. Suppose, however, that the developer decided to use the information gained in the first question to make the second more personal. If the name of the user were inserted into the second question, where would it go? The answer for the English language is well-known, but other languages may place the name in different places.
This is where the “java.text” package comes in. This package, standard in the Java Development Kit (JDK) since version 1.1, provides a means for inserting context into text messages. Now the second resource could be changed in English to be “age_question=How old are you, {0}?”. The number surrounded by curly brackets indicates that there is some generally unknown information that will replace the brackets and number. The numbering is important in case multiple entries are needed.
The code for the “Translation” class needs to be augmented to handle contextual information. The following method should be added:
Contextual translation code
// Returns contextually specific translationspublic static String getTranslation (String key, String[] lookups) {if (key == null) return “”;if (resource_bundle == null) initBundle();try {String retStr = resource_bundle.getString(key);return MessageFormat.format(retStr, lookups);} catch (Exception e) {return key;}}
Thus, resource bundles are rapidly becoming the status quo for developers desiring to write applications or web-based services that need to be delivered to a multitude of locales around the world. These bundles are made up of a collection of electronic text files organized in a tree format that serve to define lookup pairs, associating key values with translations appropriate for the various locales. While this system of internationalization can be helpful at runtime, it requires developers to go through an onerous process to create and maintain the files making up the resource bundles, typically having to edit a plurality of text files using a standard text editor to make a single change or update.
The U.S. Pat. No. 6,167,567 to Chiles et al., assigned to 3Com Corporation, provides for a technique for automatically updating software stored on a client computer in a networked client-server environment. Disclosed are scripts for updating programs across a network, including resource bundles. But, this patent fails to disclose a method for the management of such resource bundles, and it further fails to mention a method to import/export resource bundle data to other formats.
Whatever the precise merits, features, and advantages of the above-mentioned references, none of them achieves or fulfills the purposes of the present invention.